Internet Info 1997 December/Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso/ietf/urn/urn-archives/urn-ietf.archive.9703/000079_owner-urn-ietf _Fri Mar 28 14:03:50 1997.msg

Internet Message Format | 1997-04-01 | 9KB

Received: (from daemon@localhost)
    by services.bunyip.com (8.8.5/8.8.5) id OAA03865
    for urn-ietf-out; Fri, 28 Mar 1997 14:03:50 -0500 (EST)
Received: from mocha.bunyip.com (mocha.Bunyip.Com [192.197.208.1])
    by services.bunyip.com (8.8.5/8.8.5) with SMTP id OAA03859
    for <[e-mail]>; Fri, 28 Mar 1997 14:03:47 -0500 (EST)
Received: from acl.lanl.gov by mocha.bunyip.com with SMTP (5.65a/IDA-1.4.2b/CC-Guru-2b)
        id AA16901  (mail destined for [e-mail]); Fri, 28 Mar 97 14:03:44 -0500
Received: from montana (montana.acl.lanl.gov [128.165.147.143]) by acl.lanl.gov (8.7.3/8.7.3) with SMTP id MAA07116; Fri, 28 Mar 1997 12:03:40 -0700 (MST)
Message-Id: <[e-mail]>
X-Sender: [e-mail]
X-Mailer: Windows Eudora Pro Version 3.0 (32)
Date: Fri, 28 Mar 1997 12:02:28 -0700
To: Dan Connolly <[e-mail]>, [e-mail]
From: "Ron Daniel, Jr." <[e-mail]>
Subject: Re: [URN] resend of draft-urn-resolution-services-01.txt
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: [e-mail]
Precedence: bulk
Reply-To: "Ron Daniel, Jr." <[e-mail]>
Errors-To: [e-mail]

At 01:52 AM 3/28/97 -0600, Dan Connolly wrote:
>Short version:
>    (1) I suggest link types be integrated into this
>    design and
>    (2) as a result, I think that URLs and URNs can
>    be used interchangeably
>    (3) I think N2C needs another parameter to
>    specify the schema of the URC.

Short version of my reply:

1)
A few of your responses assume a much stronger link to HTTP than is
appropriate for this document. HTTP is only one of the protocols that
coud be used for a client to converse with a resolver. Z39.50, HDL,
... are others. Some of your comments should probably be directed to
the THTTP draft instead.

2)
The Name/Location thing comes up again. This group's charter is based
on the model that there is a distinction. Therefore that distinction is
axiomatic in our deliberations. So, some of your suggestions, such as
replacing N2L, L2N, ... with a single I2I operation need to be
re-examined in that light.

3)
I like the suggestions about considering part/whole and generic/specific
relations in addition to the generalized equivalance relation.



>Details:
>Michael Mealling wrote:
>> This memo gives an initial set of those operations, and the
>> requirements that must be met when those operations are encoded in a
>> protocol.
>
>"intial set" gives me the willies. Do you mean to imply
>that you'll specify the rest of the list some day? If so,
>say so.

The intent is that others may want to add operations later.


>Are the names of these operations expected to be used
>literally in extensible fields in protocols?

No, when someone proposes to use a new protocol for URN resolution, they
need to specify how these operations are mapped to tht protocol. It may
be literal use of the names, it may be something else.

>My intuition says that we're after a fiarly small set
>of primitives that doesn't need to be expanded:

I think it is fairly small, but I'm unwilling to assume it won't need
to be expanded.


>Note that N and L are both URIs. Hence my second point:
>the distinction between URNs and URLs isn't necessary.

Yes and no. Both are URIs, so an I2I method would suffice at that level.
However, this group distinguishes between names and addresses. If I have
a name and want to get an address, we need an N2L operation.

>> 4.2 N2Ls (URN to URLs)
>> This operation is used to map a single URN to 0 or more URLs.
>
>
>This one becomes:
>    Given a URI N, Return a set of URIs L[i] such that there
>    is a link from N to L[i] of type "N2L" for each i.

I'm sorry Dan, but I really don't see the benefit of your suggested
rewordings.


>> All URIs shall be encoded according to the URI specification [6].
>
>I can't find reference 6. I'm terribly curious to know which
>document you're citing for URI syntax.

RFC 1630 is what we normally use, I'm not sure if that is what Michael
was intending to cite or not. (The problems with preparing a draft
right before the deadline).

>> 4.5 N2C (URN to URC)
>...
>> URCs (Uniform Resource Characteristics) are descriptions of other
resources.
>> This request allows the client to obtain a description of the resource
>> identified by a URN, as opposed to the resource itself or simply the
>> resources URLs.
>
>FYI, the PICS spec gives an example of this operation:
>    http://www.w3.org/pub/WWW/PICS/labels.html#Requesting
>
>It has another parameter though: the metadata schema
>that the URCs should conform to.
>
>Hmm... I'll have to look closely at THTTP to see if
>it's gratuitiously different from PICS.

THTTP says that people should use format negotiation if they want
a partiular format. We are not defining the one true URC format.
In the absence of format negotiation, the resolver is free to send back
the URC info in any format it pleases. PICS, SOIF, whatever. Other
protocols, such as Z39.50, may have a different take on the matter.

>> 4.6 N2Ns (URN to URNs)
>The relationship you're talking about seems to be
>the generic/specific relationship, which is VERY useful,
>along with part/whole and a few others.

Yeah, we can talk about this.


>>  The result shall
>> be encoded in a text/uri-list IMT.
>
>s/shall/should/, no?

Agreed.  Perhaps even "may".



>> 4.7 L2Ns (URL to URNs)
>
>> This operation is used to discover the URN associated with a particular
URL.
>
>"the URN"? So this relationship is expected to be functional?
>I think that's fine, as long as it's a conscious decision.

An overstatement. Since we have N2Ns, we should say "discover A URN" not
"discover THE URN".

>Something that I think should be specified: is L2N expected
>to be the inverse of N2L?

Nope. If a resource has multiple URNs and URLs, I don't think we should
mandate any particular behavior on the part of resolvers to make stronger
mappings between the identifiers.


>> 4.8 L2Ls (URL to URLs)
>> This operation is used to discover URLs that are considered equal to each
>> other.
>
>This one is clearly supposed to be an equivalence relation.
>If N2N is also an equivalence relation, then I don't understand
>the distiction.

See earlier discussions on names vs. addresses.

>As I suggested above, I think the essentail ones are:
>    EQV : equivalence in any sense, as long as it's
>        reflexive, symmetric, and transitive. This can be
>        used for alias detection etc.
>    G2S/S2G: generic-to-specific and the converse.
>        transitive (and antisymmetric, I think).
>    P2H/H2P: part-to-whole, whole-to-part. transitive
>        and antisymmetric.
>        This sort
>        of metadata is repeatedly requested by
>        search service providers who want to
>        know when texi2html-chapter2 and
>        texi2html-chapter3 are children of
>        the same root.

I think these are good suggestions.


>Each of these is a special case of:
>    Given a URI S and a URI T, return a set of URIs D[i]
>    such that there's a link from S to D[i] of type T
>    for each i.
>
>These special cases are worth making exception,
>(since full URLs for N2L and EQV would probably waste a lot of
>bytes in DNS!) I suggest another operation for the general
>case:
>
>    S2D(URI S, URI T) -> set of URIs D[i]

Hmmm, sounds pretty good. The first question that comes up is that
sometimes we are happy mapping from one URI to another, and other times
we want to get back a specific type of URI (URN or URL). So, we need to
modify your earlier definition and this suggestion for the generic
operation.

>> 4.9 L2C (URL to URC):
>> This operation is used to retrieve the URC for a given URL
>
>How is this distinct from N2C?

I2C might be very reasonable. Anyone have any scenarios where we need
to maintain the distinction between N and L when fetching metadata?
Hmmmm - there will be times when some metadata applies to the version
of the resource at a particular location, but that is still covered by
a generic I2C operation.

>> 4.10 I2I (URI to URI):
>> This operation is used to map any arbitrary URI to any other arbitrary URI.
>
>Again, I don't see the reason for more than one equivalence
>relation.

Please reconsider this in light of this group's axiom that URNs and
URLs are both URIs, but are not equivalent.

>> 4.11 I=I (Is URI equal to URI):
>> This operation is used to determine whether two given URIs are
considered to
>> be equal by the server being asked the question.
>
>And again.

Um, are you sure about this Dan? This isn't requesting that a mapping
be performed, its a predicate on the existance of such a mapping.


Ron Daniel Jr.              voice:[phone]
Advanced Computing Lab        fax:[phone]
MS B287                     email:[e-mail]
Los Alamos National Lab      http://www.acl.lanl.gov/~rdaniel
Los Alamos, NM, USA, 87545